The invention relates generally to the field of embedded system-level design. More specifically, embodiments of the invention relate to systems and methods for increasing software functionality in an existing system-level design.
Embedded software typically pertains to software used in controllers for reactive real-time applications that are implemented as mixed software and hardware. These controllers comprise processors, microprocessors, microcontrollers, digital signal processors (DSPs), and the like. Examples of applications using embedded controllers include everyday appliances such as microwave ovens; consumer electronics such as cameras and compact disk players; automotive applications such as engine management and anti-lock brake controllers; telephony applications such as switches and cellular phones; plant automation and robotics, and many others.
Embedded software is the preferred choice for implementing application functionality in system large scale integration (LSI) designs due to lower design effort and silicon cost, and shorter product cycles associated with software as compared to custom hardware. For particular system functions that are subject to potential revision, embedded software helps prolong the market longevity of a product through the ability to support post-deployment upgrades and in-field fixes. However, several application processing tasks still necessitate the use of custom hardware since software alone cannot guarantee that all performance requirements are met. Most often the software component is used for flexibility while the hardware component is used for performance.
System-level design can be subject to many different types of constraints including timing, size, weight, power consumption, reliability, and cost. A system specification is developed and sent to hardware and software engineers. A hardware/software partition is decided a priori and is adhered to as much as is possible since any changes in the partition may necessitate extensive redesign. Designers often strive to make everything fit in software and off-load parts of the design to hardware to meet design constraints.
Codesign deals with designing heterogeneous systems. The designer has to exploit the advantages of the heterogeneity of the target architecture. In many instances, the use of processors is very economical compared with the development costs of application specific integrated circuits (ASICs). However, hardware is always used when processors are not able to meet the required performance. The tradeoff between hardware and software illustrates the optimization aspect of codesign.
The codesign process starts with specifying the system behavior at a system level. After this, a system specification is divided into a set of basic blocks. In a cost estimation step, values for some cost metrics are determined for the blocks. The cost metrics include estimations for hardware or software implementations. Hardware cost metrics include execution time, chip area, power consumption or testability. Software cost metrics include execution time and the amount of required program and data memory.
After the cost estimation has been performed, the hardware/software partitioning phase computes a mapping of the blocks to hardware or software resulting in sets of blocks implemented as hardware or software. Since the goal is a heterogeneous system-level architecture, the mapping requires additional interface parts such as communication and synchronization between ASICs and processors. All specifications include communication mechanisms to allow the exchange of data between processors and ASICs. The hardware is synthesized from the given system specification and the software specification is compiled for the chosen processor. The result of this co-synthesis phase is an ASIC or set of ASICs and a set of assembler programs for a processor or processors to execute. An example system-level architecture that results from this process is shown in FIG. 1.
Prior work in the area of hardware/software codesign has in large part concerned itself with optimizing the partitioning of tasks between software and hardware given a set of application tasks in conjunction with the current performance capabilities of hardware and embedded processors. However, over the market life of an application-specific product, the question of optimizing the hardware/software partition is often raised. For example, when a product undergoes revision to accommodate minor changes in application functionality or when a need arises to improve key design metrics such as performance, power, etc., in order to remain competitive. At each revision, it is important to consider evolutionary changes that would inevitably have occurred in the performance of hardware and software due to advances in semiconductor technologies and take them into account to address the question of repartitioning an existing design.
In many application domains, especially those that are affected by international standards, changes to application behavior are relatively infrequent due to the slow rate at which new standards or revisions to existing ones are approved and deployed. For example, the first revision to the encryption algorithms for IEEE 802.11 wireless local area networks (LANs) occurred more than five years after their introduction, while for over a decade, MPEG-2 (Motion Picture Experts Group, layer 2) remains the most popular video compression technique. In contrast, semiconductor technologies that underlie the implementations of these applications have historically demonstrated rapid and steady improvements in performance, silicon area, and power consumption. As a result, the capabilities of the underlying hardware are periodically observed to exceed the imposed requirements. In such scenarios, it is important to effectively exploit improvements in hardware capabilities to reduce design cost, time-to-market, and improve design flexibility. Sustained improvements in semiconductor technology allows for increased migration of system functionality from hardware to software. A natural way to achieve this goal over time is to reduce the amount of application-specific hardware used in the system and realize the same functionality using embedded software.
In order to remain competitive under rapidly evolving technology, design teams look to the gradual migration of application tasks from hardware to software. Typically, the system specification is reviewed, and using automatic codesign tools, a system architecture that is optimized for the new technology is arrived at. The problem is that a unified high-level model of the system and corresponding tool flows for architecture synthesis are often unavailable. Therefore, designers execute a near complete (manual) redesign of the system, starting with an informal specification of the application that leads to high cost and large turn-around times.
Previous work in hardware/software codesign targeted the initial design of a system architecture in which the partitioning of system functionality into hardware and software is optimized, starting from an implementation independent specification of system behavior. This is a process that requires significant investment of engineering resources and is conducted as infrequently as possible, potentially resulting in failure to capture emerging markets or failure to keep up with changing application requirements and feature sets.
The prior art has not satisfactorily addressed automatic techniques to support the migration of system functionality in the opposite direction—from hardware to software—in application scenarios where it is important to reduce hardware cost, increase flexibility, and reduce design turn-around-time without sacrificing performance.